Mobility operation resource allocation

ABSTRACT

According to one aspect of the present disclosure, a method and technique for mobility operation resource allocation is disclosed. The method includes: receiving a request to migrate a running application from a first machine to a second machine; displaying an adjustable resource allocation mobility setting interface indicating a plurality of mobility settings comprising at least one performance-based mobility setting and at least one concurrency-based mobility setting; receiving, via the interface, a selection of a mobility setting defining a resource allocation to utilize for the migration; and migrating the running application from the first machine to the second machine utilizing resources as set by the selected mobility setting.

BACKGROUND

In some data processing environments, an application and/or workload maybe migrated from one computing environment to another computingenvironment. For example, system virtualization is a technology whichcan divide a single host (e.g., computer, server, etc.), into multipleparts, or partitions, each running a separate instance, or image, of anoperating system. The instances of the operating systems or partitionsare separate, or isolated, from each other in some ways. For example,the partitions have separate file systems, separate users, separateapplications, and separate processes. However, the partitions may alsoshare some resources of the host. For example, the partitions can sharethe memory, the kernel, the processors, the hard drives, and/or othersoftware, firmware, and/or hardware of the host. Thus, each partition orinstance of the operating system can look and feel like a separateserver or machine from the perspective of its users. These instances arecommonly referred to as “virtual” or “virtualized” machines, and eachpartition may be referred to as a logical partition (LPAR).

One server or data processing can generally host a number of LPARs.These LPARs may also be transferred or migrated from one server orsystem to another. For example, to facilitate hardware updates or othertypes of maintenance services, an LPAR may be migrated from one serverto another without disrupting the running of an operating system andhosted applications of the migrating LPAR, thereby maintaining serviceoperability without disruption.

BRIEF SUMMARY

According to one aspect of the present disclosure a method and techniquefor mobility operation resource allocation is disclosed. The methodincludes: receiving a request to migrate a running application from afirst machine to a second machine; displaying an adjustable resourceallocation mobility setting interface indicating a plurality of mobilitysettings comprising at least one performance-based mobility setting andat least one concurrency-based mobility setting; receiving, via theinterface, a selection of a mobility setting defining a resourceallocation to utilize for the migration; and migrating the runningapplication from the first machine to the second machine utilizingresources as set by the selected mobility setting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of the present application, theobjects and advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 is an embodiment of a network of data processing systems in whichthe illustrative embodiments of the present disclosure may beimplemented;

FIG. 2 is an embodiment of a data processing system in which theillustrative embodiments of the present disclosure may be implemented;

FIG. 3 is a diagram illustrating an embodiment of a data processingsystem for mobility operation resource allocation in which illustrativeembodiments of the present disclosure may be implemented;

FIG. 4 is a diagram illustrating another embodiment of a data processingsystem for mobility operation resource allocation in which illustrativeembodiments of the present disclosure may be implemented; and

FIG. 5 is a flow diagram illustrating an embodiment of a method formobility operation resource allocation according to the presentdisclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure provide a method, system andcomputer program product for mobility operation resource allocation. Forexample, in some embodiments, the method and technique includes:receiving a request to migrate a running application from a firstmachine to a second machine; displaying an adjustable resourceallocation mobility setting interface indicating a plurality of mobilitysettings comprising at least one performance-based mobility setting andat least one concurrency-based mobility setting; receiving, via theinterface, a selection of a mobility setting defining a resourceallocation to utilize for the migration; and migrating the runningapplication from the first machine to the second machine utilizingresources as set by the selected mobility setting. Embodiments of thepresent disclosure enable the flexible selection of resources to utilizefor application migration based on performance and/or concurrencyrequirements. Embodiments of the present disclosure utilize an interfacethat enables a user/administrator to select performance-based and/orconcurrency-based settings to utilize for application migration, therebyaccommodating rapid movement of larger partitions when performance iscritical and/or migrating a greater quantity of less active partitionsconcurrently if performance is not critical. Embodiments of the presentdisclosure enable a user/administrator to apply the mobility setting(s)on a partition-by-partition basis as well as prioritize the migration ofcertain partitions.

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present disclosure may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present disclosure may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer usable or computer readablemedium(s) may be utilized. The computer readable medium may be acomputer readable signal medium or a computer readable storage medium. Acomputer readable storage medium may be, for example but not limited to,an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, apparatus, or device, or any suitable combinationof the foregoing. More specific examples (a non-exhaustive list) of thecomputer readable storage medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain, or store a program for use by or in connection with aninstruction execution system, apparatus or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present disclosure are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

With reference now to the Figures and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments of the present disclosure maybe implemented. It should be appreciated that FIGS. 1-2 are onlyexemplary and are not intended to assert or imply any limitation withregard to the environments in which different embodiments may beimplemented. Many modifications to the depicted environments may bemade.

FIG. 1 is a pictorial representation of a network of data processingsystems in which illustrative embodiments of the present disclosure maybe implemented. Network data processing system 100 is a network ofcomputers in which the illustrative embodiments of the presentdisclosure may be implemented. Network data processing system 100contains network 130, which is the medium used to provide communicationslinks between various devices and computers connected together withinnetwork data processing system 100. Network 130 may include connections,such as wire, wireless communication links, or fiber optic cables.

In some embodiments, server 140 and server 150 connect to network 130along with data store 160. Server 140 and server 150 may be, forexample, IBM® Power Systems™ servers. In addition, clients 110 and 120connect to network 130. Clients 110 and 120 may be, for example,personal computers or network computers. In the depicted example, server140 provides data and/or services such as, but not limited to, datafiles, operating system images, and applications to clients 110 and 120.Network data processing system 100 may include additional servers,clients, and other devices.

In the depicted example, network data processing system 100 is theInternet with network 130 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, network data processing system 100 also may be implemented as anumber of different types of networks, such as for example, an intranet,a local area network (LAN), or a wide area network (WAN). FIG. 1 isintended as an example, and not as an architectural limitation for thedifferent illustrative embodiments.

FIG. 2 is an embodiment of a data processing system 200 such as, but notlimited to, client 110 and/or server 140 in which an embodiment of asystem for mobility operation resource allocation according to thepresent disclosure may be implemented. In this embodiment, dataprocessing system 200 includes a bus or communications fabric 202, whichprovides communications between processor unit 204, memory 206,persistent storage 208, communications unit 210, input/output (I/O) unit212, and display 214.

Processor unit 204 serves to execute instructions for software that maybe loaded into memory 206. Processor unit 204 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 204 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 204 may be a symmetricmulti-processor system containing multiple processors of the same type.

In some embodiments, memory 206 may be a random access memory or anyother suitable volatile or non-volatile storage device. Persistentstorage 208 may take various forms depending on the particularimplementation. For example, persistent storage 208 may contain one ormore components or devices. Persistent storage 208 may be a hard drive,a flash memory, a rewritable optical disk, a rewritable magnetic tape,or some combination of the above. The media used by persistent storage208 also may be removable such as, but not limited to, a removable harddrive.

Communications unit 210 provides for communications with other dataprocessing systems or devices. In these examples, communications unit210 is a network interface card. Modems, cable modem and Ethernet cardsare just a few of the currently available types of network interfaceadapters. Communications unit 210 may provide communications through theuse of either or both physical and wireless communications links.

Input/output unit 212 enables input and output of data with otherdevices that may be connected to data processing system 200. In someembodiments, input/output unit 212 may provide a connection for userinput through a keyboard and mouse. Further, input/output unit 212 maysend output to a printer. Display 214 provides a mechanism to displayinformation to a user.

Instructions for the operating system and applications or programs arelocated on persistent storage 208. These instructions may be loaded intomemory 206 for execution by processor unit 204. The processes of thedifferent embodiments may be performed by processor unit 204 usingcomputer implemented instructions, which may be located in a memory,such as memory 206. These instructions are referred to as program code,computer usable program code, or computer readable program code that maybe read and executed by a processor in processor unit 204. The programcode in the different embodiments may be embodied on different physicalor tangible computer readable media, such as memory 206 or persistentstorage 208.

Program code 216 is located in a functional form on computer readablemedia 218 that is selectively removable and may be loaded onto ortransferred to data processing system 200 for execution by processorunit 204. Program code 216 and computer readable media 218 form computerprogram product 220 in these examples. In one example, computer readablemedia 218 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 208 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 208. Ina tangible form, computer readable media 218 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 200. The tangibleform of computer readable media 218 is also referred to as computerrecordable storage media. In some instances, computer readable media 218may not be removable.

Alternatively, program code 216 may be transferred to data processingsystem 200 from computer readable media 218 through a communicationslink to communications unit 210 and/or through a connection toinput/output unit 212. The communications link and/or the connection maybe physical or wireless in the illustrative examples.

The different components illustrated for data processing system 200 arenot meant to provide architectural limitations to the manner in whichdifferent embodiments may be implemented. The different illustrativeembodiments may be implemented in a data processing system includingcomponents in addition to or in place of those illustrated for dataprocessing system 200. Other components shown in FIG. 2 can be variedfrom the illustrative examples shown. For example, a storage device indata processing system 200 is any hardware apparatus that may storedata. Memory 206, persistent storage 208, and computer readable media218 are examples of storage devices in a tangible form.

FIG. 3 is an illustrative embodiment of a system 300 for mobilityoperation resource allocation. System 300 may be implemented on dataprocessing systems or platforms such as, but not limited to, servers 140and/or 150, clients 110 and/or 120, or at other data processing systemlocations. In the embodiment illustrated in FIG. 3, system 300 includesa server system 310 and a server system 312. Processors, memory, andother hardware resources of computer system server systems 310 and 312may be apportioned into logical partitions (LPARs) that may operateindependently, each LPAR running its own operating system andapplications. In the illustrated embodiment, server system 310 includesLPARs 320 and 322; however, it should be understood that a greater orfewer quantity of LPARs may be provisioned. LPARs are assigned a subsetof a computer's physical hardware resources (i.e., a subset of thehardware underlying the server environment) and are virtualized withinthe server environment as a separate computer/virtual machine. Resourcessuch as processor capacity, memory, or any other type of resource may beassigned to a particular LPAR. Each LPAR has its own virtual operatingsystem (OS) instance (e.g., operating systems 334 and 326 in respectiveLPARs 320 and 322), application programs (e.g., application(s) 328 and330 in respective LPARs 320 and 322) and/or associated files, allowingfor multiple operating systems to be simultaneously executing within theserver environment.

A LPAR 340 (in server system 310) and a LPAR 342 (in server system 312)is dedicated to implementing I/O functionality by executing virtual I/Oserver (VIOS) software/firmware (software, logic and/or executable codefor performing various functions as described herein (e.g., residing assoftware and/or an algorithm running on a processor unit, hardware logicresiding in a processor or other type of logic chip, centralized in asingle integrated circuit or distributed among different chips in a dataprocessing system)). The LPAR 340/342 running the VIOS software/firmwaremay be referred to herein as a VIOS LPAR or VIOS partition 340/342.Likewise, the executing VIOS software/firmware, which provides VIOSfunctionality, may be referred to herein as a VIOS. Logical partitioningis facilitated by software 346 and 348 in respective server systems 310and 312 (a “hypervisor”) that controls the computer system's hardwareand monitors the operating systems of the LPARs. Hypervisor 346/348operates at a level between the logical partition operating systemslevel and server system physical hardware. Hypervisor 346/348 may rundirectly on the computer system's hardware or within a conventionaloperating system environment, depending upon the implementation.

In the embodiment illustrated in FIG. 3, LPARs 320 and 322 are beingmigrated from server system 310 to server system 312. It should beunderstood that a single LPAR or multiple LPARs may be migrated betweendifferent hardware platforms. Further, multiple LPARs may be migratedserially or concurrently. The transfer or migration of LPARs from serversystem 310 to server system 312 is coordinated by a hardware managementconsole (HMC) 350. HMC 350, or portions thereof, may be implemented inany suitable manner using known techniques that may be hardware-based,software-based, or some combination of both. For example, HMC 350 maycomprise software, logic and/or executable code for performing variousfunctions as described herein (e.g., residing as software and/or analgorithm running on a processor unit, hardware logic residing in aprocessor or other type of logic chip, centralized in a singleintegrated circuit or distributed among different chips in a dataprocessing system). The transfer of partitions may be performed over anEthernet 352 (e.g., using iSCSI protocols) or a private Ethernet 354through respective service processors 360 and 362. Server systems 310and 312 may also be configured with access through respective VIOSpartitions 340 and 342 to an external storage subsystem 366 via astorage area network (SAN) 368. Although the description provided hereinmay be directed toward the migration of an LPAR from server system 310to server system 312, each of server systems 310 and 312 may besimilarly configured to enable the functions described herein.

Live LPAR mobility enables a running LPAR(s) with its OS andapplications to be transferred from one physical hardware platform to adifferent hardware platform. VIOS partitions 340 and 342 are configuredwith code and/or routines to provide the function of transporting thepartition sate from one hardware platform to another hardware platform.A VIOS partition with mobility capability enabled may sometimes bereferred to as a mover service partition (MSP). At least one virtualasynchronous services interface (VASI) device of the MSP enables the MSPto communicate with its respective hypervisor. Hypervisors 346/348maintain information corresponding to a state of a partition, includingthe partition's memory. During migration, hypervisors 346 and 348provide support to transfer partition information (e.g., stateinformation and a memory image) between MSP partitions. Source anddestination mover service partitions communicate with each other overthe network. On both the source and destination server systems, the VASIdevice provides communication between the MSP and the hypervisor. Tomove a partition's memory image, the hypervisor sends and tracks thepartition's memory pages relying on the source and destination MSPs toprovide central processing unit (CPU) and memory resources. If themigrating partition writes to a memory page after its information hasbeen sent to the destination MSP, the hypervisor manages re-sending thememory pages with the updated write content to enable the partition tocontinue to run during the mobility operation. Thus, data flows from thesource hypervisor on the source server system through the source MSP tothe destination MSP and down to the hypervisor on the source serversystem.

In some instances, a partition's memory page may be quite large (e.g.,if running databases). Further, the amount of VIOS CPU cycles utilizedby a hypervisor increases if the MSP needs to support mobility of largepartitions or a relatively large number of concurrent partition mobilityoperations. Accordingly, the length of time and rate of data transferfor the mobility operations are bound by the amount of memory and CPUcycles provided to the hypervisors by the MSP.

Embodiments of the present disclosure enable the selection and/orconfiguration of resources to be used for partition mobility operationsto accommodate and/or balance performance and concurrency. As indicatedabove, the length of time and rate of data transfer for the mobilityoperations is dependent on the amount of memory a hypervisor has accessto for migrating a partition's memory and the number of CPU threads usedfor managing the memory buffers. The amount of memory depends on boththe size and number of memory buffers allocated per mobility operation.Further, the amount of CPU used per mobility operation depends on thenumber of threads used and the length of time the threads run.Embodiments of the present disclosure enable the flexible selection ofmemory resources and CPU thread configuration (e.g., number and runningtime) in a way to fit concurrency versus performance needs for thepartition mobility operations. For example, for partitions withrelatively light memory usage, a larger number of concurrent operationsmay be performed at a reduced rate or a smaller quantity of concurrentoperations at a higher rate of speed.

In the embodiment illustrated in FIG. 3, HMC 350 includes an allocationmodule 370, an interface 372 and mobility configuration data 374.Allocation module 370 is used to select and/or set a desired allocationof resources for partition mobility operations. The allocation settingsmay be applied to a particular mobility operation or a set of mobilityoperations. For example, the allocation setting may be selected to applyto each partition for a mobility operation covering multiple partitions.The allocation setting may also be selected to apply and/or vary forcertain partitions (even though the mobility operation may covermultiple partitions). For example, in some embodiments, a mobilityoperation may be directed toward five different partitions(LPAR₁-LPAR₅). A particular allocation setting may be set/applied toLPAR₁, LPAR₂ and LPAR₄, while a different allocation setting may beset/applied to LPAR₃ and LPAR₅. The mobility operation may be initiatedand the different allocation settings automatically applied on apartition-by-partition basis (e.g., applying one setting for one set ofLPARs and a different setting to a different set of LPARs). Allocationmodule 370 may be implemented in any suitable manner using knowntechniques that may be hardware-based, software-based, or somecombination of both. For example, allocation module 370 may comprisesoftware, logic and/or executable code for performing various functionsas described herein (e.g., residing as software and/or an algorithmrunning on a processor unit, hardware logic residing in a processor orother type of logic chip, centralized in a single integrated circuit ordistributed among different chips in a data processing system).

Mobility configuration data 374 may comprise information associated withthe allocation of memory and/or CPU resources to apply to partitionmobility operations. For example, in the illustrated embodiment,mobility configuration data 374 includes one or more mobility settings380 comprising memory configuration data 382 and thread configurationdata 384. A particular value and/or setting for memory configurationdata 382 and thread configuration data 384 may correspond to aparticular respective memory buffer and CPU thread configuration settingfor a mobility operation. Memory configuration data 382 may correspondto a quantity and/or size of memory resources. Thread configuration data384 may correspond to a quantity of CPU threads, a running time ofthreads and/or thread prioritization. It should be understood that othertypes of resources and/or resource attributes may be correspondinglyset/allocated for the mobility operations to accommodate performanceand/or concurrency requirements.

Interface 372 is used to provide a graphical user interface (GUI) orother type of interface to enable a user/administrator to select theresource allocation configuration settings to apply to the partitionmobility operation. Interface 372 may be implemented in any suitablemanner using known techniques that may be hardware-based,software-based, or some combination of both. For example, interface 372may comprise software, logic and/or executable code for performingvarious functions as described herein (e.g., residing as software and/oran algorithm running on a processor unit, hardware logic residing in aprocessor or other type of logic chip, centralized in a singleintegrated circuit or distributed among different chips in a dataprocessing system).

In some embodiments, interface 372 may be configured to identify defaultvalues applied for memory configuration data 382 and threadconfiguration data 384 based on a particular setting 380 selected by auser/administrator. For example, in some embodiments, interface 372 maycomprise a slider bar or other type of GUI such that a particularvalue/setting on the slider bar/GUI corresponds to particular memoryconfiguration data 382 and/or thread configuration data 384 settings. Inthis embodiment, a lower slider bar/GUI value or setting may correspondto higher performance such that a greater quantity and/or larger sizememory resources are allocated and/or provided to hypervisors. Also,additional threads may be used for managing the migration of memoryinformation. With this setting, a large, active partition may bemigrated faster because the hypervisor has access to more memory andthread resources for the mobility operation. Correspondingly, a higherslider bar/GUI value or setting may correspond to greater/maximumconcurrency such that smaller sized memory resources are allocated tothe hypervisor and perhaps one thread is used to manage memoryresources. With this setting, many, less active partitions may bemigrated concurrently because the hypervisor has access to less memoryresources so more operations can be handled without impacting other VIOSoperations. In some embodiments, interface 372 may be configured toenable a user/administrator to select particular memory and/or threadallocation settings for mobility operations, thereby enabling acustomized resource allocation for mobility operations. Thus, inresponse to the selection of particular setting 380, allocation module370 allocates corresponding memory and CPU resources utilized for themobility operations. Further, in some embodiments, allocation module 370may be used to prioritize the migration of LPARs. For example, in someembodiments, a user/administrator may desire that certain migrationoperations be prioritized for certain LPARs. Allocation module isconfigured to perform the mobility operations according to the setprioritization.

In FIG. 3, allocation module 370 and mobility configuration data 374 aredepicted as part of HMC 350. FIG. 4 is an illustrative alternateembodiment of system 300 for mobility operation resource allocation. InFIG. 4, allocation module 370 and mobility configuration data 374, andcorresponding functions thereof, are implemented within VIOS partitions340 and 342. For example, in some embodiments, interface 372 of HMC 350may be used to display various mobility settings 380 that may beavailable for partition migration. In response to receiving a selectionof a mobility setting 380 and/or applicable LPARs, the selected setting380 and/or applicable LPAR information may be communicated from HMC 350to VIOS partition 340 and/or 342. In this embodiment, allocation module370 (implemented as part of VIOS partition 340 and/or 342) identifiesthe resource requirements desired for the migration based on theselected setting 380 (e.g., using memory configuration data 382 and/orthread configuration data 384), determines the availability of suchresources, and initiates the migration operation(s) based on themobility setting(s) 380 and resources allocated.

Referring to FIGS. 3 and 4, in some embodiments, VIOS partition 340and/or 342 is configured to negotiate the allocation of memory and/orCPU resources between the source MSP and the destination MSP. Forexample, in some instances, the resources available by the source MSPmay be greater than the resources available on the destination MSP, orvice versa. In this example, there may be a mismatch between availableresources between the source and destination MSPs such that the mobilitysetting 380 desired may be available from the perspective of one MSP butbe unavailable from the other MSP (or neither). In this instance, VIOSpartition 340 and/or 342 (e.g., via a respectively configured allocationmodule 370 implemented as part of VIOS partition 340 and/or 342) may beconfigured to detect the mismatch and/or unavailability of MSP resourcesand negotiate a balanced resource allocation for the mobility operationsbased on resource availability of the source and/or destination MSP. Forexample, even though a particular setting 380 may indicate a high memoryresource allocation to dedicate to the mobility operation, VIOSpartition 340 and/or 342 may override and/or automatically adjust (e.g.,without user/administrator intervention) the resource allocation toaccommodate the current availability of resources of thesource/destination MSP in view of the desired mobility setting 380.

FIG. 5 is a flow diagram illustrating an embodiment of a method formobility operation resource allocation. The method begins at block 502,where HMC 350 receives a request to migrate one or more runningapplications or LPARs. At block 504, interface 372 is displayedindicating one or more performance-based and/or concurrency-basedresource allocation settings to apply for the LPAR migration(s). Atblock 506, allocation module 370 receives one or more mobility settings380 for the migration (e.g., a single setting to apply to all migratingLPARs and/or certain settings for certain LPARs). At block 508,allocation module 370 identifies the memory resource requirementsaccording to the selected mobility setting(s). At block 510, allocationmodule 370 identifies processor resource requirements according to theselected mobility setting(s).

At block 512, VIOS partition 340 and/or 342 evaluates availableresources on the source and/or destination MSPs based on the selectedmobility setting(s). At block 514, VIOS partition 340 and/or 342negotiates any needed balance of resource allocations between the sourceand destination MSPs (e.g., that may result from a mismatch of similarand/or available resources). At block 516, a determination is madewhether resources are available based on the desired/selected mobilitysetting(s). If resources are available, the method proceeds to block520. If it is determined at decisional block 516 that resources areunavailable based on the selected mobility setting(s), the methodproceeds to block 518, where VIOS partition 340 and/or 342 overrides theselected mobility setting based on the available resources. At block520, VIOS partition 340 and/or 342 allocates the resources for themigration. At block 522, the LPAR(s) are migrated utilizing theallocated resources.

Thus, embodiments of the present disclosure enable the flexibleselection of resources to utilize for application migration based onperformance and/or concurrency requirements. Embodiments of the presentdisclosure utilize an interface that enables a user/administrator toselect performance-based and/or concurrency-based settings to utilizefor application migration, thereby accommodating rapid movement oflarger partitions when performance is critical and/or migrating agreater quantity of less active partitions concurrently if performanceis not critical. Embodiments of the present disclosure enable auser/administrator to apply the mobility setting(s) on apartition-by-partition basis as well as prioritize the migration ofcertain partitions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present disclosure has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the disclosure in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the disclosure. Theembodiment was chosen and described in order to best explain theprinciples of the disclosure and the practical application, and toenable others of ordinary skill in the art to understand the disclosurefor various embodiments with various modifications as are suited to theparticular use contemplated.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

1. A method, comprising: receiving a request to migrate a runninginstance of an operating system and an application from a first machineto a second machine; displaying an adjustable resource allocationmobility setting interface indicating a plurality of mobility settingscomprising at least one performance-based mobility setting and at leastone concurrency-based mobility setting; receiving, via the interface, aselection of a mobility setting defining a resource allocation toutilize for the migration; and migrating the running instance of theoperating system and the application from the first machine to thesecond machine utilizing resources as set by the selected mobilitysetting.
 2. The method of claim 1, further comprising negotiating abalance of resource allocations between the first machine and the secondmachine based on the selected mobility setting.
 3. The method of claim1, further comprising identifying a memory resource allocation for themigration based on the selected mobility setting.
 4. The method of claim3, further comprising determining processor utilization for themigration based on the selected mobility setting.
 5. The method of claim1, further comprising: allocating greater memory resources for theperformance-based mobility setting than for the concurrency-basedmobility setting; and allocating a greater quantity of threads for theperformance-based mobility setting than for the concurrency-basedmobility setting for managing the memory resources.
 6. The method ofclaim 1, further comprising automatically overriding the mobilitysetting in response to identifying unavailable resources correspondingto a resource allocation indicated by the mobility setting.
 7. A method,comprising: receiving a request to migrate a plurality of logicalpartitions from a first machine to a second machine, each logicalpartition comprising a running instance of an operating system;displaying an adjustable resource allocation mobility setting interfaceindicating a plurality of mobility settings, each mobility settingcorresponding to a desired resource allocation to utilize for themigration; receiving, via the interface, a first mobility setting toapply to a first set of logical partitions of the plurality of logicalpartitions and a second mobility setting to apply to a second set oflogical partitions of the plurality of logical partitions; andinitiating migration of the first and second sets of logical partitionsfrom the first machine to the second machine utilizing the resourceallocations as set by the respective first and second mobility settings.8. The method of claim 7, wherein the first mobility setting is aperformance-based mobility setting and the second mobility setting is aconcurrency-based mobility setting.
 9. The method of claim 7, furthercomprising negotiating a balance of resource allocations between thefirst machine and the second machine based on the first and secondmobility settings.
 10. The method of claim 9, further comprisingautomatically overriding the resource allocation indicated by either thefirst or second mobility settings in response to identifying unavailableresources on either the first or second machines.
 11. The method ofclaim 7, further comprising identifying a memory resource allocation forthe migration based on the first and second mobility settings.
 12. Themethod of claim 11, further comprising identifying a processor resourceallocation for the migration based on the first and second mobilitysettings.
 13. The method of claim 8, further comprising: allocatinggreater memory resources for the first mobility setting than for thesecond mobility setting; and allocating a greater quantity of threadsfor the first mobility setting than for the second mobility setting formanaging the memory resources.
 14. A method, comprising: receiving arequest to migrate from a first machine to a second machine a pluralityof logical partitions (LPARs) each running an instance of an operatingsystem and an application; displaying an interface comprising aplurality of selectable mobility settings, each mobility settingcorresponding to a desired resource allocation to utilize for themigration, wherein a first mobility setting sets a first resourceallocation to accommodate a desired rate of migration, and wherein asecond mobility setting sets a second resource allocation to accommodatea desired concurrency of LPAR migrations; receiving, via the interface,a selection of a mobility setting to apply for migrating the LPARs; andinitiating migration of the LPARs from the first machine to the secondmachine utilizing resources as set by the selected mobility setting. 15.The method of claim 14, further comprising setting an amount of memoryon the first and second machines to allocate to the migration and aquantity of threads to use on the first and second machines for themigration based on the selected mobility setting.
 16. The method ofclaim 15, further comprising, in response to detecting a mismatchbetween the amount of memory on the first machine and the amount ofmemory on the second machine to allocate to the migration based on theselected mobility setting, negotiating a balance of resource allocationon the first and second machines based on available resources on thefirst and second machines.
 17. The method of claim 16, furthercomprising receiving a different selected mobility setting for each ofthe plurality of LPARs and automatically applying the respectiveselected mobility settings to the respective migrations of the LPARs.18. The method of claim 17, further comprising setting a run time forthe threads based on the selected mobility setting.
 19. The method ofclaim 18, further comprising evaluating available resources on the firstand second machines based on the selected mobility setting.
 20. Themethod of claim 1, wherein: each selectable mobility setting sets anamount of memory on the first and second machines to allocate to themigration and a quantity of threads to use on the first and secondmachines for the migration; and further comprising determiningavailability of the amount of memory and the quantity of threads on thefirst and second machines for the migration based on the selectedmobility setting and, in response to determining an unavailability ofthe amount of memory or the quantity of threads on either the first orsecond machines for the migration, negotiate a balance of memory andthreads to use on the first and second machines to use for themigration.